AWRL6432 Intruder Detection Demo Users Guide

Table of Contents

Overview

This lab demonstrates the use of TI AWRL6432 mmWave sensors for an intruder detection system for a 2-row vehicle that is capable of continuosly monitoring the interior and immediate exterior proximity of a vehicle. Such systems are often very power hungry and can be a big load for a battery, drastically reducing the charge of an EV vehicle. The AWRL6432 mmWave sensors enables this use case to be performed at a very low average power, resulting in a longer battery life. This lab outputs a 3D point cloud over UART, which is then utilized by a detection state machine in the accompanying MATLAB visualizer.

Requirements

Hardware Requirements

Item Details
AWRL6432 Evaluation Board AWRL6432 ES1.0 Evaluation Board
Computer PC with Windows 10. If a laptop is used, please use the ‘High Performance’ power plan in Windows.
Micro USB Cable Due to the high mounting height of the EVM, a 15ft+ cable or USB extension cable is recommended.

Additional Software Requirements

Tool Version Download Link
MATLAB Runtime 2019a (9.6) Exact version required. https://www.mathworks.com/products/compiler/matlab-runtime.html

⚠️ Run Out of Box Demo
Before continuing with this lab, users should first run the out of box demo for the EVM. This will enable users to gain familiarity with the sensor’s capabilities as well as the various tools used across all labs in the Radar Toolbox.

Quickstart

1. Follow xwrL64xx/14xx MCU+ SDK

Follow the steps from the SDK, which can be found here

2. Mount the EVM and Create Test Environment

Mount the sensor at the desired location securely so that the sensor is stable during runtime. Update the desired configuration file so that it reflects the device’s location. More information on mounting can be found in the section below.

3. Launch the Visualizer

🛑 MATLAB Runtime Version R2019a (9.6) Required
Exact version R2019a (9.6) required.

  1. Launch the visualizer executable located at <PACKAGE_LOCATION>\tools\visualizers\InCabin_IntruderDetection_GUI\
  2. Double click to launch InCabin_IntruderDetection_visualizer.exe.
  3. A black console window will appear. After 30-60sec, a configuration window will appear as shown below.

4. Config Visualizer

  1. Select the EVM Control and Data COM ports using the respective dropdowns.

  2. You should see the Chirp configuration file automatically selected in the Configuration dialogue. But if the configuration file is not the correct one, browse to select a file provided in the config_file directory: <PACKAGE_LOCATION>\tools\visualizers\InCabin_IntruderDetection_GUI\config_file

  3. Select Real Demo mode and press Go! to start the Visualizer.

  4. Select Index for recording file if users plan to record the point cloud for future playback

  5. The Visualizer window will appear as shown below and after several seconds, the visualizer should start showing the point cloud and occupancy decisions in their respective panels:

5. Understand the Visualizer

The Visualizer window is divided into five panels as shown in the annotated picture above:

  1. Statistics: This section prints real-time information from the target: Frame number, both processed and (target), and a Zone table that displays the occupancy state, number of detections in the zone, and average SNR of the detections. When the Count button is clicked, the Points column becomes the “Frame” count (total number of frames that have been counted), and the SNR column becomes “Count” - the number of frames with positive occupancy state.

  2. Chirp Configuration: This panels shows the static chirp configuration loaded at startup time.

  3. Control: This panel provides an Exit button, a Record button (saves frame by frame point cloud and occupancy data). In addition, there are two sub-panels, which independently allows either the Occupancy Display to be paused, or selection/pausing of a display in the Point Cloud panel.

  4. Occupancy: This panel pictorally displays the output of presence detection. The interior of the car will declair to be occupied if any of the defined zone is occupied.

  5. Point Cloud: This panel can display one of several displays: “2D Point Cloud” shows and overhead view of the detected points, along with the zone boundaries when that zone decision is positive.

6. Re-playing previously saved output

As described in the previous section, the InCabin_IntruderDetection_visualizer can save the EVM UART output (point cloud information) in files named fHistRT_xxxx.mat where each file can contain up to 1000 frames of information. These saved fHist files can be re-played offline by running InCabin_IntruderDetection_visualizer.exe as shown below:

  1. Navigate to <PACKAGE_LOCATION>\tools\visualizers\InCabin_IntruderDetection_GUI\

  2. Copy the previously saved fHistRT_xxxx.mat files to the directory above

  3. Launch the same visualizer InCabin_IntruderDetection_visualizer.exe, select the mode as Playback instead of Real Demo and select the preferred file index for the recorded file, and and press Go! to start the playback as shown in the figure below. In playback mode, the port numbers are no longer relevant, but a matching chirp configuration is still needed.

Configuration Statistics

Parameter Value
Range Resolution 0.0488 m
Maximum Range 2.8 m
Velocity Resolution 0.778 m/s
Maximum Velocity 3.11 m/s
Average Power Consumption 10-20 mW*

*to estimate power based on configuration settings see the Sensing Estimator tool

Algorithm Overview

This demo can be viewed as two pieces: the device running the radar code and the host running the visualizer. The device code is the same demo as xwrL64xx/14xx MCU+ SDK OOB Demo, and information related to that part of the algorithm can be viewed in the SDK OOB documentation.

Zone Mapping

After the point cloud is sent to host through UART. Inside the visualizer, the point cloud is first transformed into car coordination. Then mapped to different zones. Each zone is defined through a sequence of cuboids using cuboidDef CLI command. The details can be found in the high accuracy VOD demo user’s guide

This zone mapping idea has been reused for all the in-cabin sensing demo, including localization, intruder detection, presence detection and etc.

For different application, users may need to define different zones. For in-cabin localization, a common practice is to define each seat as one zone. For this intruder detection demo, users can define the entire interior of car (including footwear region) as one zone. Close proximity zones are defined to be just outside of the doors of the car. However with overhead mounting, we observe some false detection right under the sensor, which is caused by the strong floor reflection, we call it, static leakage. This type of false detection can be controlled through CFAR threshold adjustment based on angle and distance, which is however not yet supported in the current target code. Therefore, in our example, we define different zones and apply different detection threshold in the state machine to help with this problem.

Occupancy Detection State Machine

After zone mapping, the occupancy detection state achine is running to determine the occupancy status for each zone using a number of factors that can be configured by the occStateMach CLI command. The general idea is that a zone can be detected as occupied only if the total number and quality (average SNR) of the detected point cloud within the zone are higher than the pre-determined threaholds. The occupacy state machine is shown in the following figure

The occStateMach CLI holds the thresholds for enter-condition1, enter-condition2, stay-condition, forget-condition, and overload condition.

Users can define same or different zoneType for each zone through zoneNeighDef CLI. By introduce zoneType, the system can have multiple sets of occupancy detection thresholds. For example, the interior of the car experiences stronger SNR relative to the proximity zones defined to be outside of the car, causing the detection of a presence inside of the vehicle to be easier. Therefore, it makes sense to use a higher set of thresholds for the interior region; the proximity zones will experience weaker SNR and higher rate of miss detection. Therefore, users can consider to use a lower set of thresholds to cover the outside of the vehicle. Note that the occupancy detection state machine is reused for all the in-cabin sensing demo, and therefore, could have been an over-design for the intruder detection. For example, the overload condition logic is not really needed for intruder detection. Therefore, users should program a big value for overload condition, so that overload condition will never be triggered.

Users can find the detail definition of each parameter of occStateMach and zoneNeighDef at CLI list session.

EVM Mounting and Coordinate Transforms

The detected point cloud is all relative to the sensor. In order to make occupancy decision for each seat in the car, we need to transform the point cloud from sensor coordinates to the car coordinates. There are different position and different mounting angle that can be considered for mounting the device. To give the full flexibility, “sensorPosition” CLI is used to indicate the mounting offset in (x, y, z) and mounting rotation angle in y-z plane, x-y plane and x-z plane. Based on these offsets and tilting angles, the visualizer will transform the point cloud from the sensor coordinate to the car coordinate. The car coordinate is plotted in the left figure below. Here we provide one example:

Users can find more mounting examples in the setup guide

Demo Specific Configuration File Parameters

In addition to the standard xwrL64xx MCU+ SDK CLI commands (please refer to the SDK’s user guide for these commands), there are some additional commands that are specific to this demo visualizer:

Command Parameters (in command line order)
sensorPosition offset in x direction, in meter
offset in y direction, in meter
offset in z direction, in meter
clockwise rotation angle in y-z plane, in degree
clockwise rotation angle in x-y plane, in degree
clockwise rotation angle in x-z plane, in degree
numZones number of zones to define, min = 5, max = 8. The first 5 zones must correspond to the zone numbers shown in the Occupancy Display. If you only want 2 operational zones, define the others as NULL zones. (see cuboidDef below).
totNumRows number of rows in the car for occupacy detection.
occStateMach zone type: the state machine allow different thresholds for different zone now, use zone type to seperate them. In our example, we use a different set of thresholds for middle seat.
enter-condition1: number of detected points in a zone to enter the occupied state
enter-condition1: average SNR of detected points in a zone to enter the occupied state
enter-condition2: number of detected points in a zone to enter the occupied state
enter-condition2: average SNR of detected points in a zone to enter the occupied state
numEntryThreshold: every of continuous frames that the zone is passing the occupancy condition.
stay-condition: number of detected points in a zone to remain in the occupied state
stay-condition: average SNR of detected points in a zone to remain in the occupied state
forget-condition: number of frames with less than ceiling points (see next parameter) to hold occupied state before dropping
forget-condition: ceiling points (max points) in a zone during “hold” frames.
overload-condition: average SNR in a zone to declare overload condition (excessive movement). Causes state machine to freeze all the zones.
interiorBounds min X (azimuth) -X towards passenger side, +X towards driver side (zone1)
max X (azimuth)
min Y (depth) 0: brake padel, +Y towards the rear
max Y (depth)
cuboidDef parent zone number (1 based)
cuboid number within the zone (also 1 based). min = 1, max = 3 per zone
min X (azimuth)
max X (azimuth)
min Y (depth)
max Y (depth)
min Z (height) 0.0 is the car floor
max Z (height) should not be higher than the car roof.
(Note: to define a NULL zone, define it with a single cuboidDef command setting all X,Y,Z values to 0.0)
zoneNeighDef zone ID
zone type: defined to allow different set of threshold in occStateMach. In our example, we use different zone type of middle seat than the rest of the seats.
numNeigh: number of neighbor. When adding a neighbor to a zone, the enter-condition2 for the zone is enhanced. Specifically, the avgSNR for enter-condition2 has to be larger than the avgSNR of all its defined neighbors. We have found this method useful to reduce the false detection in the middle seat.
neighbors: define the zone ID for each neighbor.

Performance Tuning

The key items to focus on for tuning are as follows:

Need More Help?